Computer-implemented method and system for security event transport using a message bus

ABSTRACT

A computer-implemented device provides security events from publishers to subscribers. There is provided a message bus, configured to contain a plurality of security events. Also provided is a receiver unit, responsive to a plurality of publishers, to receive the plurality of security events from the publishers. There is also a queue unit, responsive to receipt of the security events, to queue the plurality of security events in the message bus. Also, there is a transport unit, responsive to the security events in the message bus, to transport the plurality of security events in the message bus to a plurality of subscribers.

RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/317,231, entitled “Computer-Implemented Method and System forSecurity Event Transport Using a Message Bus,” filed Dec. 27, 2005,which claims the benefit of U.S. Provisional Patent Application Ser. No.60/699,378, entitled “Computer-Implemented Method and System forSecurity Event Correlation,” filed on Jul. 15, 2005, the contents ofwhich are hereby expressly incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to computer systems, and morespecifically to managing security events that occur in a computingenvironment.

2. Description of the Related Art

In today's computing environment, threats to the security of computersystems are increasing both in frequency and in complexity.Unfortunately, an organization can lose assets, time, and even customersdue to threats that successfully breach its computing environment orthat exploit flaws in its information infrastructure.

It would not be unusual for a large installation to have more than twothousand devices included in the security of the network. The timelyidentification and resolution of security incidents is imperative.However, effectively handling the increasing number of perimeter sourcesand/or applications and the increasing load of message packets generatedfrom the devices can be overwhelming. Moreover, the ever-growing volumesof data can mask suspicious activity, or limit its detection in a timelyfashion.

A conventional database-centric architecture requirements multipledatabases, and relies on database mapping to obtain vulnerabilityinformation, which affects database performance and further cannot bereadily leveraged, such as in reports. This also affects the ability toscale up the architecture to very large environments, since data tendsto be accessed through a central point. A representative conventionaldatabase-centric architecture is illustrated in the block diagram ofFIG. 1. Generally these are set up in a hierarchical architecture, withmultiple databases 105, 115, 119 distributed throughout the system tostore various security event information. As security events aredetected in the system, security event information is stored locallythroughout the architecture, such as at each of several local computers121, each of which can have an event manager process 117 and a database119 of local security events. Upper level computers 111 can receiveinformation regarding security events from various collections of localcomputers 121, can process the information at a security event manager113, and each can store security event information at a local database115. A divisional manager 125 can manage 123 the upper level computers111. A user can access security information via a master console manager101, which includes its manager processing 103 and a local database 105.Alternatively, users can access subsets of security information viadivisional consoles 107, which include manager processing 109 and canaccess the databases of subsets of security events.

The database in a database-centric architecture inherently becomes thebottleneck to performance and scalability. For example, screenrefreshes, correlation analyses, and queries require database reads,inserts, or look ups. The amount of users can affect the database'sability to respond in real time when operating at high rates of speed.Unfortunately, database-centric approaches cannot effectively handleevent bursts such as can occur during an attack, because the database isrelied on for many aspects of event management. Other performance issuescan result as well.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

The accompanying figures where like reference numerals refer toidentical or functionally similar elements and which together with thedetailed description below are incorporated in and form part of thespecification, serve to further illustrate an exemplary embodiment andto explain various principles and advantages in accordance with thepresent invention.

FIG. 1 is a block diagram illustrating a representative prior artcomputing environment for processing security events.

FIG. 2 is a block diagram illustrating a simplified and representativeexample architecture for use in connection with security events, inaccordance with one or more embodiments.

FIG. 3 is a block diagram illustrating exemplary queues of securityevents, in accordance with one or more embodiments.

FIG. 4 is a block diagram illustrating an exemplary message bus ofsecurity events, in accordance with one or more embodiments.

FIG. 5 is a block diagram illustrating portions of an exemplarycomputer, in accordance with various exemplary embodiments.

FIG. 6 is a flow chart illustrating an exemplary procedure for receivingsecurity events from publishers, in accordance with various exemplaryand alternative exemplary embodiments.

FIG. 7 is a flow chart illustrating an exemplary procedure for queuingsecurity events in a message bus, in accordance with various exemplaryand alternative exemplary embodiments.

FIG. 8 is a flow chart illustrating an exemplary procedure fortransporting security events to subscribers, in accordance with variousexemplary and alternative exemplary embodiments.

DETAILED DESCRIPTION

In overview, the present disclosure concerns computer networks andcomputer systems, such as an intranet, local area network, distributednetwork, or the like having a capability of detecting security events.Such computer networks and computer systems may further provide servicessuch as communications. A computing network environment can be incommunication with various components, generally referred to herein assecurity components, which include a feature that can detect and provideinformation on security events. More particularly, various inventiveconcepts and principles are embodied in systems, devices, and methodstherein for providing information associated with security events.

The following detailed description includes many specific details. Theinclusion of such details is for the purpose of illustration only andshould not be understood to limit the invention. Throughout thisdiscussion, similar elements are referred to by similar numbers in thevarious figures for ease of reference. In addition, features in oneembodiment may be combined with features in other embodiments of theinvention.

It is further understood that the use of relational terms such as firstand second, and the like, if any, are used solely to distinguish onefrom another entity, item, or action without necessarily requiring orimplying any actual such relationship or order between such entities,items or actions. It is noted that some embodiments may include aplurality of processes or steps, which can be performed in any order,unless expressly and necessarily limited to a particular order; i.e.,processes or steps that are not so limited may be performed in anyorder.

Much of the inventive functionality and many of the inventive principleswhen implemented, are best supported with or in software or integratedcircuits (ICs), such as a digital signal processor and softwaretherefore or application specific ICs. It is expected that one ofordinary skill, notwithstanding possibly significant effort and manydesign choices motivated by, for example, available time, currenttechnology, and economic considerations, when guided by the concepts andprinciples disclosed herein will be readily capable of generating suchsoftware instructions or ICs with minimal experimentation. Therefore, inthe interest of brevity and minimization of any risk of obscuring theprinciples and concepts according to the present invention, furtherdiscussion of such software and ICs, if any, will be limited to theessentials with respect to the principles and concepts used by theexemplary embodiments.

As further discussed herein below, various inventive principles andcombinations thereof are advantageously employed to reduce bottleneckscreated by database-centric architectures. One or more embodimentsprovides security event processing in a publish-subscribe architectureutilizing a message bus.

Referring now to FIG. 2, a block diagram illustrating a simplified andrepresentative example architecture for use in connection with securityevents in accordance with one or more embodiments will be discussed anddescribed. In overview, one or more embodiments provide for a messagebus 205, together with a transport unit 203, and/or a queuing unit 207.Security events can be collected and forwarded to the queuing unit 207to be placed into the message bus 205. The transport unit 203 can be incommunication with one or more subscribers, such as subscribers A-D 201a-201 d. Security events can be provided, for example in connection withthe transport unit 203, to one or more subscribers 201 a-201 d.

The security events can be provided from security components; in theillustrated example, the security components include a securityperimeter source 213, a referential IT source 215, an operating system217, and an application event 219. The security events are collected byone or more collectors, here represented by collectors 211 a, 211 b.Here, each of the collectors 211 a, 211 b collects security events fromdifferent security components.

The collectors 211 a, 211 b can act as publishers, for example bypublishing the security events. In the illustrated example, thecollectors 211 a, 211 b provide the collected security events toreceiver units, here represented by receiver units 209 a, 209 b.Accordingly, one or more embodiments provide that the at least onepublisher includes a plurality of collectors, each of the collectorscollecting data from security components and, responsive to the data,providing the security events to the receiver unit. Each receiver unit209 a, 209 b can receive the collected security events from one of thepublishers, and forward the security events to be queued, for example bythe queuing unit 207.

In accordance with one or more embodiments, a collector can aggregatesecurity events from security components. One or more collectors can beconfigured as desired for aggregating security events. Data in securityevents that are collected by a collector can be normalized, and theformat can be standardized into one or more pre-selected formats.

The queuing unit 207 can queue one or more security events into themessage bus 205. For example, the queuing unit 207 can receive thesecurity event or retrieve the security event to be queued; determine aparticular position in the message bus 205 responsive to, e.g., securityevent content or security event origin; and queue the security eventinto the queue at the particular position.

The transport unit 203 can retrieve security events from the message bus205, and publish the security events to subscribers, e.g., subscribers201 a-201 d, who have selected receipt of events such as the retrievedsecurity event. The transport unit 203 can determine which of thesubscribers the event is to be published to based on parametersincluding one or more of, for example, subscriber type, system to whichthe subscriber belongs, security event type, security event source,date/time, or any other parameter or combination of parameters asdesired which are available from the security event in the message bus205.

In accordance with one or more embodiments, the transport unit 203 cancreate a subscription list for one of more subscribers on request, andcan modify the subscription list on request. Subscribers can subscribeto type of security events that they wish to receive. The transport unit203 can have access to the subscription lists, and can use thesubscription lists to determine which subscribers are to receivesecurity events.

A meter unit 221 can be provided, responsive to the message bus 205. Themeter unit can provide a window into the message bus 205, examining thestate of the message bus and its components, and/or controlling messagebus parameters and contents, and/or monitoring activity in the messagebus 205. For example, the meter unit 221 can display metrics of themessage bus 205 and/or the contents of the message bus 205 and/or anylogical or physical subdivisions of the message bus 205. Metrics caninclude statistical summary and deviation information about securityevents entering and/or being transported from the message bus 205, andcan reflect current and/or historical information.

Accordingly, one or more embodiments can provide a meter, responsive tosecurity events in the message bus, to dynamically determine metrics ofthe security events in the message bus and to provide the metrics forfurther use. For example, the metrics can be provided for displays,statistics, reporting, alarming, and/or logging and the like.

One or more of the subscribers, for example, represented by subscriberA-D 201 a-201 d, can register as a subscriber, request service forparticular events, and/or request automatic start of services.

The subscribers A-D 201 a-201 d, the transport unit 203, the queuingunit 207, the receiver units 209 a-209 b, and the collectors 211 a-211 bcan execute on any host computer in communication with the message bus205.

Any type of publish/subscribe implementation can be utilized, forexample, list-based publish/subscribe, broadcast-basedpublish/subscribe, and content-based publish/subscribe. In list-basedpublish/subscribe, security events can be transported to particularsubscribers based on a list; lists can be maintained for topics andassociated subscribers to those topics; associated subscribers can benotified as an event with a particular topic occurs. In broadcast-basedpublish/subscribe, security events can be broadcast to all or a part ofsubscribers, and the subscribers can filter out unwanted securityevents. In content-based publish/subscribe, security events can betransported to particular subscribers based on the content of thesecurity events.

In a message bus according to one or more list-based publish/subscribeembodiments, for a security event queued in the message bus 205, thetransport unit 203 can look up interested subscribers and can send thosesubscribers a copy of the security event.

In a message bus according to one or more a broadcast-basedpublish/subscribe embodiments, for a security event queued in themessage bus 205, the transport unit 203 can broadcast a security eventto all the subscribers that are listening to the bus. The transport unit203 does not need to determine the appropriate subscribers, because itis assumed that the subscribers can filter out unwanted security events.

In a message bus according to one or more content-basedpublish/subscribe embodiments, for a security event queued in themessage bus 205, the transport unit 203 can match a security eventagainst a subscription list indicating certain subscribers and thenforward the security event to the indicated subscribers. To match thesecurity event to certain subscribers, the transport unit 203 can judgewhether there is a match between selected content in the security eventa set of values corresponding to one or more subscribers; if a matchexists between the security event content and subscriber(s), thesecurity event can be forwarded to the matching subscribers.

Security events can be sent from the security components 213, 215, 217,219. Security events are generally known in the industry. A securityevent can be a discrete packet of data including information which istypically defined by the manufacturer and can be particular to a type ofsecurity component, e.g., to a particular brand and product type or thelike. The security event definition can provide for various informationfields, sometimes referred to as “tags.” For example, conventionally themanufacturer of a security component can define the particular tags andranges of data to be expected in the particular tags, where the tags areassociated with a type of security component.

Accordingly, one or more embodiments can provide for acomputer-implemented device for providing security events frompublishers to subscribers. The computer-implemented device can include amessage bus, configured to contain a plurality of security events; areceiver unit, responsive to a plurality of publishers, to receive theplurality of security events from the publishers; a queue unit,responsive to receipt of the security events, to queue the plurality ofsecurity events in the message bus; and a transport unit, responsive tothe security events in the message bus, to transport the plurality ofsecurity events in the message bus to a plurality of subscribers. One ormore embodiments provide that the security events enter and exit themessage bus in an orderly manner; more particularly, one or moreembodiments provide that security events are queued and de-queued in themessage bus in an orderly manner; even more particularly, one or moreembodiments provide that there is a single message bus, a single queueunit interfacing with the message bus, and/or a single transport unitinterface with the message bus.

Any process or device referencing, receiving, or forwarding a securityevent can filter the security event so that only information of furtherinterest is passed along and/or stored. Any filtering can be done inaccordance with pre-determined patterns.

For example, the collectors 211 a, 211 b, receiver unit 209 a, 209 b,and/or the queuing unit 207 can parse/normalize security events toachieve a standardized format, impose a taxonomy, add data as desired,and/or filter out based on relevance e.g. defined in a filter. Asanother example, the collectors 211 a, 211 b can include vulnerabilitydata as one of the security events which can be forwarded for furtherprocessing, and can be eventually queued into the message bus 205.Vulnerability scanners are commercially available, can check securitycomponents and/or systems of security components against knownvulnerabilities and can provide vulnerability data reporting potentialsecurity holes.

In accordance with the illustrated embodiment, it is not necessary forpeer components (such as subscribers, receiver units, collectors, andsecurity components) to communicate directly with each other.

One or more embodiments of the above-described subscribers, transportunit, queuing unit, receiver unit, and/or collector can utilizeutilities, including taxonomy, business relevance, and/or exploitdetection utilities. These are described below in more detail.

With regard to a taxonomy utility, security components can producesecurity events in different formats with varying content. The taxonomyutility can translate heterogeneous data of the security events intocommon terms and product homogeneous security events. Optionally, thetaxonomy can filter selected security events out, or add additional dataor context to the security events before they are forwarded for furtherprocessing.

With regard to the business relevance utility, business relevantcontextual data can be indicated in a security event. Business relevantcontextual data can include fields, customizable by a user, forindicating business unit, owner, asset value, and/or geographyassociated with a security event or responsive to data indicated in thesecurity event. The business relevant contextual data can then beavailable for use in connection with downstream processing.

In connection with the exploit detection utility, attacks which havebeen detected can be notified to users. Also, the exploit detectionutility can link intrusion detection system (IDS) signatures andvulnerability scanners (examples of vulnerability scanners are thosereferred to as ISS REAL SECURE, SNORT and NESSUS). Furthermore, theexploit detection utility can review vulnerability scan results whichare loaded, parse the vulnerability scan results, and provide theresults to collectors such as those associated with an IDS, so that thecollector(s) associated with a particular IDS can assign a priority tosecurity events in response to a priority for the particular IDSassigned in the vulnerability scan results.

Further, one or more embodiments of the exploit detection utility canalert users to a severity level of an attack against an asset. Moreover,one or more embodiments of the exploit detection utility can filterfalse positives and negatives.

Referring now to FIG. 3, a block diagram illustrating exemplary queuesof security events in accordance with one or more embodiments will bediscussed and described. An exemplary message bus 301 is illustrated, inwhich security events 303 a, 303 b, 303 c can be queued for furtherprocessing and perhaps later access. The security events 303 a, 303 b,303 c that are received are placed in one or more queues in the messagebus 301. Here, the illustrated message bus 301 can utilize at least onepersistent queue 305 a, at least one durable queue 305 b, and at leastone transient queue 305 c. One or more alternative embodiments canutilize one or more persistent queues, durable queues, and/or transientqueues.

Transient queues 305 c can be provided in local memory, which can becleared when the message bus task or processor running the message bustask terminates processing. Durable queues 305 b can be provided in oneor more files that can be stored for later access; the files remain evenif the message bus task terminates processing. Persistent queues 305 acan be provided in which security events can be stored in a database forlater access. The message bus 301 can be defined so that events arequeued into any combination of persistent, durable and transient queues305 a, 305 b, 305 c.

Accordingly, one or more embodiments provide that the message busfurther includes a plurality of queues, each of the queues correspondingto a different priority, the priority being user-defined, wherein eachof the security events is associated with a priority, and wherein thequeue unit queues each security event in the corresponding queue.

By utilizing transient, durable and/or persistent queues, a user candetermine reliability and fault tolerance. For instance, security eventscan be stored in the transient queue, and security events with selectedindicia can be stored not only in the transient queue, but also in thedurable queue.

In the event of a failure (such as a power failure), the security eventsin the durable queue can be recovered and re-processed. As anotherexample, one or more security events with selected indicia can be storednot only in the transient queue, but also in the persistent queue; asecurity event in the persistent queue can remain there until anotherpredetermined event occur (such as handling an alarm related to thesecurity event.

The message bus can be provided in any appropriate implementation, forexample, an IMS implementation, a Java implementation, a Linuximplementation, variants thereof, or the like. One or more embodimentsprovide that the durable, persistent, and transient queues can be usedalone, in combination with channels, and/or one or more of the channelscan be provided as durable, persistent, and/or transient queues, asfurther described herein.

It will be appreciated that the use of the message bus as a queue canpreserve a sequence of security events. Accordingly, one or moreembodiments can be scaled by adding or omitting publishers and/orsubscribers as desired, while continuing to preserve sequences ofsecurity events.

Referring now to FIG. 4, a block diagram illustrating an exemplarymessage bus of security events in accordance with one or moreembodiments will be discussed and described. The message bus 401 canfurther be divided into two or more different channels 403 a-403 c. Thethree channels illustrated in FIG. 4 are representative of any number ofdifferent channels.

Security events can be assigned to particular channels in response tothe communication path (that is, the publisher of the event, thesubscriber to the event, intermediate recipient(s) of the event,physical destination(s) of the event, or combination thereof), type ofthe security event, priority of the security event, other field in thesecurity event, or the like, or combination thereof. In the illustratedembodiment, security events are assigned to particular channels inresponse to the communication path associated with the security event.In the illustrated embodiment, the communication path includes thesubscriber to the event, where subscribers are grouped together by hostcomputer, and a channel is assigned to the subscribers on one or morehost computers. Where channels are related to a communication path, aproblem or failure in one of the communication paths can avoid affectingother channels.

A channel can provide a minimal pre-determined bandwidth, for varioussecurity events in the message bus. One or more of the channels can beassigned a specified size, for example by interaction with an operator,or by being assigned a statistical size (such as average, maximum,minimum) associated with the security events assigned to or historicallypresent in the particular channel The specified size assigned to thechannel(s) can be re-determined, for example, by re-calculating thestatistical size. The time for re-determining can be set by a schedule,can be periodic, and/or can be responsive to contents of one or morechannels 403 a-403 c or the message queue 401 reaching a threshold.

Accordingly, one or more embodiments provide that the message busincludes a plurality of channels, each of the channels corresponding topartitioned bandwidth reserved in the message bus responsive topredefined types of at least one of security events, aggregated securityevents, and security information; and wherein the queue unit queues theat least one of security events, aggregated security events, andsecurity information in the corresponding channel.

Consequently, a configuration of one or more embodiments can beconfigured to allow for large numbers of security components having fewsecurity events; whereas another configuration can be configured toallow for a few security components with a large volume of securityevents.

A channel can carry data including data on security events. Optionally,a channel can carry information relating to the channel, that is statusinformation and/or control information. Status information can indicate,for example, a status of a subscriber as it relates to its ability toreceive security event information. Control information can indicate,for example, how communication to a subscriber is to be controlled, forexample, to start up or shut down event reception, and/or more involvedprotocols for controlling communication to a subscriber.

In the illustrated embodiment, the message bus 401 includes channels A,B and C 403 a-c. One or more embodiments provide that one or more of thechannels can be further subdivided into sub-channels in response to, forexample, a type of the security event, a priority of the security event,an other field in the security event, or the like, or combinationthereof, and/or can control and status information separate from relateddata (security events). In the illustrated embodiment, separatesub-channels are provided to contain security event information (eventsub-channels 405 a), control information (control sub-channels 405 b),and status information (status sub-channels 405 c).

The utilization of multiple channels and/or sub-channels can promote theparallel processing of events and can reduce contention and/or permitarbitration for system resources.

In one or more realizations, a high throughput communication channel canhave a high data throughput rate. Optionally, security events andrelated control and/or status information can be compressed and/orencrypted either before being queued or prior to transmission to asubscriber.

Referring now to FIG. 5, a block diagram illustrating portions of anexemplary computer in accordance with various exemplary embodiments willbe discussed and described. The computer 501, such as acomputer-implemented device, may include one or more controllers 503.The controller 503 can be operably connected to a communication port 529for sending and receiving transmissions on a network, a text and/orimage display 505, and/or a user input device such as a keyboard 507.The controller 503 can also include a processor 509 and a memory 511.

The processor 509 may comprise one or more microprocessors and/or one ormore digital signal processors. The memory 511 may be coupled to theprocessor 509 and may comprise a read-only memory (ROM), a random-accessmemory (RAM), a programmable ROM (PROM), and/or an electrically erasableread-only memory (EEPROM). The memory 511 may include multiple memorylocations for storing, among other things, an operating system, data andvariables 513 for programs executed by the processor 509; computerprograms for causing the processor to operate in connection with variousfunctions such as receiving security events from publisher(s) 515,queuing security events in the message bus 517, transporting securityevents in the message bus to subscriber(s) 519, determining the metricsof security events in the message bus 521, providing a display ofsecurity events in the message bus 523, and other optional processing525; a database 529 for example of information used in connection withthe security event message bus; and a database (not illustrated) ofother information used by the processor 509. The computer programs maybe stored, for example, in ROM or PROM and may direct the processor 509in controlling the operation of the computer 501.

The processor 509 may be programmed for receiving security events fromone or more publisher(s) 515. The security events can have a variablelength and can have different formats, as previously described.Optionally, vulnerability data can be received or otherwise obtained.Optionally, the received security events can be further associated withother data, such as vulnerability data. Further, optionally,non-security events may be received from one or more publisher(s). Thesecurity events can be forwarded for queuing in the message bus. One ormore embodiments can provide that the non-security events and/orvulnerability data are also forwarded for queuing in the message bus.One or more embodiments can provide that the security events,non-security events and/or vulnerability data are transformed into astandard format before being forwarded for queuing in the message bus.Alternatively, all or a portion of the data in a security event can behomogeneous when received from the publisher. Additionally, one or moreembodiments can provide that additional information, such as taxonomy,detection information, and/or business relevant information, can beassociated with one or more of the security events that are to be queuedin the message bus.

Accordingly, one or more embodiments provide that the receiver unitfurther receives vulnerability data, determines security events in themessage bus corresponding thereto, and associates the vulnerability datawith the corresponding security event or non-security event.

Further accordingly, one or more embodiments provide that the receiverunit further enriches the security events in the message bus byassociating at least one of taxonomy, detection information, andbusiness relevance information with at least some of the security eventsin the message bus.

The processor 509 may be programmed for queuing security events in themessage bus 517. Security events which were forwarded for queuing can beplaced in the message bus. One or more embodiments provide that thesecurity events are queued in the same order as received. Alternativeembodiments provide that the security events are queued in time order,e.g., responsive to a time stamp.

Further, one or more embodiments can provide persistent, durable, and/ortransient queues; can check whether a security event is to be queued inone or more of the persistent, durable, and/or transient queues; and canqueue the security event as indicated.

Moreover, one or more embodiments can provide plural channels in themessage queue; can check first criteria for determining the one of theplural channels in which the security event is to be queued; and canqueue the security event in the channel. Also, one or more embodimentscan provide plural sub-channels in one or more channels; can checksecond criteria for determining the one of the plural sub-channels inwhich the security event is to be queued; and can queue the securityevent in the sub-channel.

One or more alternative embodiments can provide that the processor 509can also queue non-security events and/or vulnerability data that wereforwarded for queuing in the message bus. The non-security events and/orvulnerability data can be queued in persistent, durable, and/ortransient queues, and/or in channels/sub-channels, in one or moreembodiments.

The processor 509 may be programmed for transporting security eventsfrom the message bus to subscriber(s) 519. A subscriber can provide anindication of security events that are of interest. The security eventswhich are in the message bus can be retrieved and transported to theappropriate subscribers. For example, a next security event can beobtained from the message bus and transported to those subscribers thathave indicated that it is of interest. Where there are plural queues,plural channels and/or plural sub-channels in the message bus, anyappropriate de-queuing algorithm may be utilized to determine the nextqueue, channel and sub-channel from which to obtain a security event.One or more alternative embodiments can provide that the processor 509can also transport non-security events and/or vulnerability data thatwere queued in the message bus.

Optionally, one or more embodiments can provide that the processor 509is programmed for determining the metrics of security events in themessage bus 521. For example, the metrics can include statistics anddeviation information about the security events that are in and/or havebeen in the message bus. Optionally, a log of information used fordetermining metrics can be collected and stored, for example, the mostrecent eight hours of security events. The metrics which are to bedetermined can be selective, and can include any portion of theinformation that is provided in the security events. One or moreembodiments can also provide metrics on non-security events and/orvulnerability data that are queued in the message bus. The metrics canbe forwarded for reporting, logging, and/or for display, for example onthe text and/or image display 505.

The processor 509 may be programmed for providing a display of securityevents in the message bus 523. For example, the security events can beexamined and selectively displayed to a user on the display 505 or otherdisplay device. The display can be dynamic, that is, updated to reflectsecurity events currently in the message bus. The display can be updateddynamically on a periodic basis or as the content of the message buschanges. Alternatively, the display can be provided in hardcopy and/orstored in a file. The display of security events can be provided aloneand/or in combination with a display of the metrics. One or moreembodiments can also provide metrics on non-security events and/orvulnerability data that are queued in the message bus. Accordingly, oneor more embodiments provide for a dynamic display representative of thesecurity events in the message bus.

Optionally, other components may be incorporated in the computer 501 toproduce other actions. For example, a user can interface with thecomputer 501, via a known user interface such as OUTLOOK, WINDOWS,and/or other commercially available interfaces. Further, the computer501 can send and receive transmissions via known networking applicationsoperating with the communications port 529 connected to a network, forexample, a local area network, intranet, or the Internet and supportsoftware.

It should be understood that various embodiments are described herein inconnection with logical groupings of programming of functions. One ormore embodiments may omit one or more of these logical groupings.Likewise, in one or more embodiments, functions may be groupeddifferently, combined, or augmented. For example, in one or moreembodiments, the security events are received and queued, andaccordingly the computer 501 can omit one or more functions oftransporting security events in the message bus to subscribers 519,determining the metrics of security events in the message bus 521,and/or providing a display of security events in the message bus 523.Moreover, one or more embodiments can omit the function of receivingsecurity events from publishers 515 and queuing security events in themessage bus 517. Further, one or more embodiments can omit the functionsof determining metrics of the security events 521 and/or providing adisplay of security events in the message bus 523. Also, in one or moreembodiments, the functions of receiving security events 515, queuingsecurity events 517, transporting security events in the message bus tosubscribers 519 may be performed predominantly or entirely on one ormore remote computers (not illustrated); and therefore such functionscan be reduced or omitted from the processor 509 and distributed to theremote computer. Similarly, the present description may describe variousdatabases or collections of data and information. One or moreembodiments can provide that databases or collections of data andinformation can be distributed, combined, or augmented, or providedlocally (as illustrated) and/or remotely (not illustrated).

The user may invoke functions accessible through the keyboard 507. Asalternatives to the keyboard 507, or in addition to the keyboard 507,one or more other various known input devices can be provided, such as akeypad, a computer mouse, a touchpad, a touch screen, a trackball,and/or a pointing device. The keyboard is optional for one or moreembodiments.

The computer 501 can include or be connected to the text and/or imagedisplay 505, upon which information may be displayed. The display isoptional for one or more embodiments. The display 505 may presentinformation to the user by way of a conventional liquid crystal display(LCD) or other visual display, and/or by way of a conventional audibledevice (such as a speaker, not illustrated) for playing out audibleinformation.

The computer 501 can include one or more of the following, notillustrated: a floppy disk drive, a hard disk drive (not shown), and aCD ROM or digital video/versatile disk, at internal or external harddrives. The number and type of drives can vary, as is typical withdifferent configurations, and may be omitted. Instructions for operatingthe processor 509 can be provided electronically, for example, from thedrive, via the communication port 529, or via the memory 511.Accordingly, one or more embodiments provide for a computer-readablemedium comprising instructions for execution by a computer, where theinstructions include a computer-implemented method for processingsecurity events.

FIG. 6, FIG. 7 and FIG. 8 are flow charts illustrating exemplaryprocedures for receiving security events from publishers, queuingsecurity events in the message bus, and transporting security events tosubscribers. Any of these procedures can advantageously be implementedon, for example, a processor of a controller, such as was described inconnection with FIG. 5, or other apparatus appropriately arranged. Eachof these illustrations is discussed below.

Accordingly, one or more embodiments can include a method for processingsecurity events, including receiving a plurality of security events fromat least one publisher; queuing the plurality of security events in amessage bus, responsive to receipt thereof; and transporting, by acomputer, the plurality of security events in the message bus to aplurality of subscribers.

Referring now to FIG. 6, a flow chart illustrating an exemplaryprocedure 601 for receiving security events from publishers, inaccordance with various exemplary and alternative exemplary embodimentswill be discussed and described. In overview, the procedure 601 providesfor receiving 603 a security event from a publisher, or vulnerabilitydata; checking 605 whether what was received is vulnerability data andif so, associating 613 vulnerability data with corresponding securityevents and/or non-security events in the message bus; checking 607whether security events are to be enriched, and if so, associating 615taxonomy, detection information and/or business relevance informationwith the security event; forwarding 609 the security event to be queued;and ending 611 processing. Each of these is discussed in more detailbelow.

The procedure 601 can include receiving 603 a security event from apublisher, or vulnerability data. Optionally, the security events thatare received are provided in a standardized format. Each security eventcan be received and processed in real-time as it is received, ratherthan being received and processed in a batch mode or similar. Securityevents can be received from one or more publishers of events.

One or more embodiments of the procedure 601 can receive data that isnot necessarily a security event, such as vulnerability data. Therefore,the procedure 601 can provide for checking 605 whether what was receivedis vulnerability data. If the data is vulnerability data, the procedure601 can associate 613 the vulnerability data with corresponding securityevents and/or non-security events in the message bus. For example, thevulnerability data can specify that certain security components have anincreased vulnerability; the procedure 601 can search the message busfor security events and/or non-security events related to those securitycomponents, and can associate information reflecting the increasedvulnerability with those security events and/or non-security events. Ifthe data was vulnerability data, the procedure 601 can loop to receivethe next security event.

Further, the procedure 601 can provide for checking 607 whether securityevents are to be enriched, and if so, associating 615 taxonomy, exploitdetection information, and/or business relevance information with thesecurity event. An indicator can be provided to instruct that securityevents are to be enriched. Such an indicator can be, for example, aparameter referenced by the procedure and/or a parameter associated witha particular security event. If security events are to be enriched,additional information can be included in the security event. Forexample, the procedure 601 can associated 615 taxonomy, detectioninformation and/or business relevance information (discussed above) withthe security event.

The procedure 601 also can provide for forwarding 609 the security eventto be queued, for queuing in the message bus, in accordance with aprocedure for queuing the security events. For example, a message withthe security event can be transmitted to the procedure for queuing thesecurity events. Thereafter, processing of the security event ends 611.

Referring now to FIG. 7, a flow chart illustrating an exemplaryprocedure 701 for queuing security events in a message bus, inaccordance with various exemplary and alternative exemplary embodimentswill be discussed and described. The procedure 701 generally can includethe following: receiving 703 a security event from the receiver;determining 705 whether queuing by priority is enabled, and if so,determining 713 the priority associated with the security event anddetermining the queue in the message bus associated with the priority;determining 707 the channel in the message bus in which to queue thesecurity event; queuing 709 the security event in the message bus andoptionally in the priority queue; and ending 711 the procedure. Each ofthe foregoing is explained in more detail below. The procedure 701 canbe repeated as desired to handle entries in the message bus.

The procedure 701 can provide for receiving 703 a security event, wherethe security event has likely been sent from the receiver. Securityevents can be received in accordance with any convention method forcommunicating between procedures. The method of receiving securityevents can reflect the order in which the security events were received,so that security events can be processed in the order in which theyoccurred. One or more embodiments can provide analogous processing forhandling non-security events.

Further, once the security event has been received, the procedure 701can provide for determining 705 whether queuing by priority is enabled.Priority queuing enabled can be indicated, for example, by an indicatorin the procedure 701 or in the security event. If queuing by priority isenabled, the procedure 701 can provide for determining 713 the priorityassociated with the security event, for example from a field in thesecurity event, a table listing security components with priority, orthe like. The procedure 701 can then determine the queue in the messagebus associated with the priority. Optionally, more than one queue can beassociated with a priority.

Having determined a priority queue (if any), the procedure 701 also canprovide for determining 707 the channel in the message bus (or in thepriority queue) in which to queue the security event. One or moreembodiments also provides for determining the channel in which to queuean aggregated security event, and/or security information, for thesecurity event. For example, this procedure 701 or another procedure cancollect information on plural security events and forward the aggregatedsecurity event information just as it would a security event, forqueuing into the message bus. Additionally, the procedure 701 canprovide for determining any sub-channel in which to queue the securityevent and/or information derived from the security event. If, forexample, there are sub-channels for holding specific subsets of securityevents, the procedure 701 can determine which sub-channel corresponds tothe security event, security event information, or non-security event.

Also, the procedure 701 can provide for queuing 709 the security eventin the message bus and optionally in the priority queue. The securityevent can be queued into the message bus, channel and/or sub-channel,and in one or more particular priority queues, in accordance withconventional queuing techniques. Thereafter, the procedure can end 711.

Referring now to FIG. 8, a flow chart illustrating an exemplaryprocedure 801 for transporting security events to subscribers, inaccordance with various exemplary and alternative exemplary embodimentswill be discussed and described. In overview, the procedure 801 caninclude determining 803 the next channel and/or queue in the message busfrom which to retrieve the next security event; getting 805 the nextsecurity event; and if 807 there is a next security event, determining809 the subscribers for the security event; transporting 811 thesecurity event to those subscribers; and de-queuing 813 the securityevent from the message bus. Each of these is described in more detailbelow.

The procedure 801 can provide for determining 803 the next channeland/or queue in the message bus from which to retrieve the next securityevent. If the message bus has plural priority queues, channels, and/orsubchannels, the procedure 801 must determine from which one to get thesecurity event. The order in which the priority queues, channels, and/orsub-channels are handled can be defined in accordance with various knowntechniques. For example, a round-robin de-queuing technique may call forhandling one security event from each sub-channel, in round-robin order.Alternatively, a de-queuing technique may call for handling all of thesecurity events in the highest priority queue first, before turning to anext lower priority queue. Other de-queuing techniques and variation maybe implemented, as well.

Also, the procedure 801 can provide for getting 805 the next securityevent from the determined queue, channel, and/or sub-channel, once it isdetermine where to retrieve the next security event. If there is no nextsecurity event in the determined queue, channel, and/or sub-channel, theprocedure 801 can loop to repeat the foregoing steps, i.e., to determinethe next priority queue, channel or sub-channel from which to retrievethe next security event.

Further, the procedure 801 can provide, if 807 there is a next securityevent, determining 809 the subscribers that are to receive the securityevent. Consider an example where the subscribers have indicated types ofsecurity events to which they subscribe. The procedure 801 can maintaina list of security event types and corresponding subscribers. Once thesecurity event is retrieved, the subscription list can be reviewed todetermine corresponding subscribers.

Also, the procedure 801 can provide for transporting 811 the securityevent to those subscribers. The security event is communicated to thosesubscribers that are to receive the security event in accordance withany of several known communication techniques. For example, if one ofthe subscribers is a local process, then for example an inter-processcommunication can notify the subscriber of the security event; if one ofthe subscribers is connected via the Internet, the communication can beperformed in accordance with Internet protocol. The security event canbe communication to all of the indicated subscribers.

The procedure 801 can then provide for de-queuing 813 the security eventfrom the message bus. Optionally, information representative of thesecurity event and the transport transaction (e.g., date, time,subscribers) can be logged. Having handled a security event in themessage bus, the procedure 801 can repeatedly loop through the messagebus to handle other security events in the message bus.

A communications capability that may be utilized in connection with oneor more embodiments can include, for example, short range wirelesscommunications capability normally referred to as WLAN (wireless localarea network) capabilities, such as IEEE 802.11, Bluetooth, or Hiper-Lanand the like using CDMA, frequency hopping, OFDM (orthogonal frequencydivision multiplexing) or TDMA (Time Division Multiple Access) accesstechnologies and one or more of various networking protocols, such asTCP/IP (Transmission Control Protocol/Internet Protocol), UDP/UP(Universal Datagram Protocol/Universal Protocol), IPX/SPX (Inter-PacketExchange/Sequential Packet Exchange), Net BIOS (Network Basic InputOutput System) or other protocol structures. Alternativelycommunications may be provided in accordance with a LAN using protocolssuch as TCP/IP, UDP/UP, IPX/SPX, or Net BIOS via a hardwired interfacesuch as a cable and/or a connector.

Furthermore, the security components of interest may include, withoutbeing exhaustive, security perimeter resources, referential informationtechnology sources, operating systems, and application events, moreparticularly referred to as firewalls, routers, intrusion detectionsystems, scanners, bridges, routers, switches, computer terminals,laptops, workstations, servers, mainframes, virtual packet networks(VPN), anti-virus applications, host intrusion detection system (IDS),network IDS, asset management, patch management, identity management,vulnerability management, business applications, domain controllers,custom applications generating events, relational data base managementsystems (RDBMS), and the like, although other examples are possible aswill be appreciated by one of skill in the art. Security components canbe programmed to detect and transmit an event, where the event includesdata corresponding to a security event, in accordance with knowntechniques. Security components that are connected to a server cancommunicate in accordance with one or more of various known protocols.For example, some security components communicate in accordance withSNMP protocol, others via SYSLOG messages, some via serial communicationprotocol, etc. The server can receive the event transmitted by thesecurity component, and can recognize the event, as is taught inaccordance with conventional techniques, and hence will not be furtherdescribed herein.

One or more embodiments may be utilized in connection with a generalpurpose computer, a specially programmed special purpose computer, apersonal computer, a distributed computer system, calculators, handheld,laptop/notebook, mini, mainframe, and super computers, as well asnetworked combinations of the same.

One or more embodiments may rely on the integration of variouscomponents including, as appropriate and/or if desired, hardware andsoftware servers, database engines, and/or other content providers. Oneor more embodiments may be connected over a network, for example theInternet, an intranet, or even on a single computer system. Moreover,portions can be distributed over one or more computers, and somefunctions may be distributed to other hardware, in accordance with oneor more embodiments.

Further, portions of various embodiments can be provided in anyappropriate electronic format, including, for example, provided over acommunication line as electronic signals, provided on floppy disk,provided on CD ROM, provided on optical disk memory, etc.

Any presently available or future developed computer software languageand/or hardware components can be employed in various embodiments. Forexample, at least some of the functionality discussed above could beimplemented using Visual Basic, C, C++, Java, or any assembly languageappropriate in view of the processor being used.

One or more embodiments may include a process and/or steps. Where stepsare indicated, they may be performed in any order, unless expressly andnecessarily limited to a particular order. Steps that are not so limitedmay be performed in any order.

This disclosure is intended to explain how to fashion and use variousembodiments in accordance with the invention rather than to limit thetrue, intended, and fair scope and spirit thereof. The invention isdefined solely by the appended claims, as they may be amended during thependency of this application for patent, and all equivalents thereof.The foregoing description is not intended to be exhaustive or to limitthe invention to the precise form disclosed. Modifications or variationsare possible in light of the above teachings. The embodiment(s) waschosen and described to provide the best illustration of the principlesof the invention and its practical application, and to enable one ofordinary skill in the art to utilize the invention in variousembodiments and with various modifications as are suited to theparticular use contemplated. All such modifications and variations arewithin the scope of the invention as determined by the appended claims,as may be amended during the pendency of this application for patent,and all equivalents thereof, when interpreted in accordance with thebreadth to which they are fairly, legally, and equitably entitled.

1. A computer-implemented device for providing security events frompublishers to subscribers, comprising: a message bus, configured tocontain a plurality of security events; a receiver unit, responsive to aplurality of publishers, to receive the plurality of security eventsfrom the publishers; a queue unit, responsive to receipt of the securityevents, to queue the plurality of security events in the message bus;and a transport unit, responsive to the security events in the messagebus, to transport the plurality of security events in the message bus toa plurality of subscribers.
 2. The device of claim 1, wherein themessage bus further includes a plurality of queues, each of the queuescorresponding to a different priority, the priority being user-defined,wherein each of the security events is associated with a priority, andwherein the queue unit queues each security event in the correspondingqueue.
 3. The device of claim 1, wherein the message bus includes aplurality of channels, each of the channels corresponding to partitionedbandwidth reserved in the message bus responsive to predefined types ofat least one of security events, aggregated security events, andsecurity information; and wherein the queue unit queues the at least oneof security events, aggregated security events, and security informationin the corresponding channel.
 4. The device of claim 1, furthercomprising a meter, responsive to the security events in the messagebus, to dynamically determine metrics of the security events in themessage bus and to provide the metrics for further use.
 5. The device ofclaim 1, wherein the at least one publisher includes a plurality ofcollectors, each of the collectors collecting data from securitycomponents and, responsive to the data, providing the security events tothe receiver unit.
 6. The device of claim 1, wherein the receiver unitfurther receives vulnerability data, determines security events andnon-security events in the message bus corresponding thereto, andassociates the vulnerability data with corresponding security events andnon-security events.
 7. The device of claim 1, wherein the receiver unitfurther enriches the security events in the message bus by associatingat least one of taxonomy, detection information, and business relevanceinformation with at least some of the security events in the messagebus.
 8. A computer-implemented method for processing security events,comprising: receiving a plurality of security events from at least onepublisher; queuing the plurality of security events in a message bus,responsive to receipt of the security events; and transporting, by acomputer, the plurality of security events in the message bus to aplurality of subscribers.
 9. The method of claim 8, wherein there areprovided a plurality of queues in the message bus, each of the queuescorresponding to a priority, the priority being user-defined, whereineach of the security events is associated with a priority, and whereineach security event is queued in the corresponding queue.
 10. The methodof claim 8, wherein the message bus comprises a plurality of channels,each of the channels corresponding to bandwidth which is partitioned andreserved in the message bus responsive to predefined types of at leastone of security events, aggregated security events, and securityinformation.
 11. The method of claim 8, further comprising dynamicallydetermining metrics of the security events in the message bus,responsive to the security events therein; and providing the metrics forfurther use.
 12. The method of claim 8, wherein the at least onepublisher includes a plurality of collectors, each of the collectorscollecting data from security components and, responsive to the data,providing the security events to be queued.
 13. The method of claim 8,further comprising receiving vulnerability data, determining securityevents in the message bus corresponding thereto, and associating thevulnerability data with corresponding events.
 14. The method of claim 8,further comprising providing a dynamic display representative of thesecurity events in the message bus.
 15. The method of claim 8, furthercomprising enriching the security events in the message bus byassociating at least one of taxonomy, detection information, andbusiness relevance information with at least some of the security eventsin the message bus.
 16. A computer readable medium comprisinginstructions for execution by a computer, the instructions including acomputer-implemented method for processing security events, theinstructions for implementing the steps of: receiving a plurality ofsecurity events from a plurality of publishers; queuing the plurality ofsecurity events in a message bus, responsive to receipt of thereof; andtransporting the plurality of security events on the message bus to aplurality of subscribers.
 17. The computer readable medium of claim 16,wherein there are provided a plurality of queues in the message bus,each of the queues corresponding to a different priority; wherein eachof the security events is associated with a priority; and furthercomprising instructions for queuing each security event in thecorresponding queue.
 18. The computer readable medium of claim 16,wherein the message bus comprises a plurality of channels, each of thechannels corresponding to bandwidth reserved in the message busresponsive to predefined types of at least one of security events,aggregated security events, and security information; and furthercomprising instructions for queuing the at least one of security events,aggregated security events, and security information in thecorresponding channel.
 19. The computer readable medium of claim 16,further comprising instructions for dynamically determining metrics ofthe security events in the message bus, responsive to the securityevents therein; and providing the metrics for further use.
 20. Thecomputer readable medium of claim 16, wherein the plurality ofpublishers includes a plurality of collectors; and further comprisinginstructions corresponding to each of the collectors for collecting datafrom security components and, responsive to the data, providing thesecurity events to be queued.
 21. The computer readable medium of claim16, further comprising instructions for receiving vulnerability data,determining security events in the message bus corresponding thereto,and associating the vulnerability data with corresponding securityevents.
 22. The computer readable medium of claim 16, further comprisinginstructions for providing a dynamic display representative of thesecurity events in the message bus.
 23. The computer readable medium ofclaim 16, further comprising instructions for enriching the securityevents in the message bus by associating at least one of taxonomy,detection information, and business relevance information with at leastsome of the security events in the message bus.